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Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard. Distribution of this memo is 
unlimited. 

Abstract 


The new generation of multimedia applications demands new features 
and new mechanisms for proper performance. ATM technology has moved 
from concept to reality, delivering very high bandwidths and new 
capabilities to the data link layer user. In an effort to anticipate 
the high bandwidth-delay data link layer, Delta-t [Delta-t], NETBLT 
[RFC 988], and VMTP [RFC 1045] were developed. The excellent 
insights and mechanisms pioneered by the creators of these 
experimental Internet protocols were used in the design of Xpress 
Transfer Protocol (XTP) [XTP92] with the goal of eventually 
delivering ATM bandwidths to a user process. This RFC is a vehicle 
to inform the Internet community about XTP as it benefits from past 
Internet activity and targets general-purpose applications and 
multimedia applications with the emerging ATM networks in mind. 


1. Introduction 


Networking is no longer synonymous with analog telephony. High- 
performance lower-layer networks have made possible exciting new 
applications: collaboratory environments, distributed client/server 
computing, remote conferencing, teleclassrooms, and distributed 
life-sciences imaging. These applications normally demand a great 
deal of bandwidth and often create operating system bottlenecks. 
Enabling these new multimedia applications entails delivering 
bandwidth to the applications, not just having bandwidth available on 
the network. This statement may appear obvious, but often solutions 
at the transport layer are satisfied by having bandwidth at that 
layer without sufficient sensitivity to higher-layer access to the 
bandwidth. The unavailability of bandwidth at upper layers is 
becoming the real issue as the networks are becoming a high- 
performance virtual backplane without concomitant high-performance 
control schemes. It appears that new services are needed that 
require communication with all layers. The ATM architecture calls 
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for such an integrated control scheme. 
Remote Conferencing 


The challenges of remote conferencing is an application whose 
challenges may be met at the data link layer by the emerging 
broadband networks. If so, important medical applications such as 
medical imaging for diagnosis and treatment planning would be 
possible [CHIM92]. Remote conferencing would permit imaging 
applications for life sciences through the use of national resource 
centers. Collaboratory conferences in molecular modeling, design 
efforts, and visualization of data in numerous disciplines could 
become possible. 


At the Second Packet Video Workshop, held December, 1992, at MCNC in 
the Research Triangle Park, North Carolina, a recurrent theme was the 
use of multimedia in remote conferencing. Its applications included 
the use of interactive, synchronized voice and video transmission, 
multicast transmission, data transfer, graphics transmission, 
noninteractive video and audio transmission, and data base query 
within a virtually shared workspace. A few participants doubted the 
ability of current computer networks to handle these multimedia 
applications and preferred only connection-oriented, circuit-switched 
services. Most participants, however, looked forward to using an 
integrated network approach. 


1. Remote Conferencing Functions and Requirements 


Remote conferencing as seen at the workshop requires a set of 
functions. It must provide session scheduling that deals with 
initiating a session, joining in-progress sessions, leaving a session 
without tearing it down if there are multiple participants, and 
terminating a session. 


The remote-conferencing session needs a control subsystem that is 
either tightly controlled for an n-to-n connection for two to 15 
participants, or loosely controlled for a 1-to-n connection for any 
number of participants. The Multipeer-Multicast Consortium is 
working on defining the control requirements and the mechanisms for 
control. At the Packet Video Workshop, one participant presented a 
conference control protocol (CCP) shown in Figure 1 [CCP92]. In this 
architecture the CCP controls the Network Voice Protocol (NVP) 
[RFC741] and the Packet Video Protocol (PVP) [PVP81] over the 
experimental Internet Stream Protocol, Version 2 (ST-II) [RFC1190] 
rather than IP. 


Latency and intramedia synchronization and intermedia synchronization 
(lip-sync) are critical for the interactive voice and video streams 
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of remote conferencing. Client/server applications including data 
base operations are equally important. The ability to display 
noninteractive video and high-resolution graphics is necessary. 


As with most applications, security will eventually be an issue. At 
the very least, there must be a mechanism to determine who can find 
out what about conference and who can join a conference. This 
determination will be part of an upper-layer protocol. 


+-------------—- + +-------- + +----- + +------------ + 
|Teleconference| | File | |Email| | Domain | 
| (CCP) | |Transfer| | | |Name Service| 
+----+------- +-+ +----—- +--+ +-+---+ +----- +------ + 
| | =| | 
| [| | 
+----- +--+ +--+----- + +-++-+ +----+---+ 
|Network | | Packet | |r tl | uU |] 
| Voice | | Video | |se | D | 
|Protocol| |Protocol | | Pp | | P | 
+---+----+ +--+----- + +-+--+ +--+----- + 
| 


+-+---+--+ A ------- +-+ 
| Stream | | I | 
|Protocol| | P | 
+---+----+ +---+------- + 
eee Seca eee TER 
| IEEE_802.X,FDDI,DARTnet, ATOMIC... | 
$--------------------------------- + 


Figure 1: The Connection Control Protocol Architecture 


The solutions must range in geography from single machines through 
LAN, CAN, MAN, WAN conferences, as well as in data content from PCs 
to high-end workstations. Implicit in the scaling is the notion of 
product and application interoperability. 


Remote conferencing applications should take advantage of future 
network enhancements, as well as the functions provided by ATM, FDDI, 
and SMDS. Doing so should provide function versus resource trade- 
offs such as cost versus error control and cost versus rate control. 
As a result, the transport layer should be able to provide the 
services offered by the data link layer. 


Most of the presentation on remote conferencing indicated a need for 
some degree of multicast functionality, ranging from the 1-to-n, with 
conference membership completely known, to conferences for which 
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existence of a group is known, but exact membership is not. 


In remote conferencing, it is preferable to use one network for all 
information traffic. This network should have an offered quality of 
service (QOS) criteria to accommodate tradeoff metrics, which would 
include guaranteed throughput, connection reliability, high call- 
completion rate, few dropped calls, tolerable error rate, varying 
degrees of compression on the video and audio streams, and tolerable 
motion artifacts, flow control, and latency. The QOS should be an 
input to the transport layer from the application or transport 
service user. 


The compression/coding function should provide time-stamping and 
packetizing information, as well as real-time echo cancellation. 
These functions are usually at the presentation and session layer of 
the Open System Interconnection (OSI) model or the at the application 
in some Internet models, but not the transport layer. 


3. Potential Solutions 


RFC 1193 deals with the requirements of real-time communications, 


which include some of the same capabilities [RFC1193]. But the 
requirements articulated create the necessity for new 
transport/network protocols. The new protocols under development by 


the Audio Visual Transport [SCHU92] (RTC, RTCP), and other protocols 
in this area (ST-II) suggest an architecture like that shown in 
Figure 2. 


These approaches may work. However, they encourage a discipline that 
creates a protocol for each new class of application. Another 
approach might be to unify the protocols. It is felt that this is 
one of the main goals of XTP (see Figure 3). 


Other design considerations of XTP include the following: 
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+----- +----- + | P | 
|ST-II| UDP | | 
+ toss +---+------ 
| | IP | 
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| Data Link Layer 
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Figure 2: One emerging multimedia architecture 
+-------------- ay Sap + +----- + +------------ +4+----------- + 
| Teleconference | | File | |Email| | Domain | | media | 
| |Transfer| | | |Name Service||application| 
+------ +------- + +----+---+ 4+--4+--+ 4----- +------ +4+----- +----- + 
| | | 
+--------------- +-------- +---------- #osSoSeSSSS555 + 
| 
$-SSSS55 +-------- + 
|Unified Protocol | 
PaaS SaaS Sea + 
|Data Link Layer | 
+---------------- + 
Figure 3: Another integrated multimedia architecture 
(1) Developing a protocol based on the work and experience of 


the protocol groups such as IETF, which produced NETBLT, 
VMTP, TCP, IP, and UDP. 


Incorporating lessons from Delta-t. 


Observing the design paradigm shift of ATM, SONET, and VMTP 
in the header, trailer, and information segment construction. 


Targeting the real-time requirements articulated by the 
Department of Defense SAFENET committee and the French 
Ministry of Defense military real-time specification [GAM-T-103]. 


Mechanisms in XTP allow an application to approach the performance 
desired. A session-scheduling mechanism for joining and leaving a 


Chimiak 


[Page 5] 


RFC 1453 Comments on Video Conferencing April 1993 


multicast conference exists. The XTP mechanism for multicast 
satisfies the loosely controlled session requirements. The tightly 
controlled session would require the use of multiple XTP 
associations. 


The priority mechanism that uses the 32-bit SORT field permits an 
application to prioritize data. Because XTP is a transport layer, 
this priority mechanism follows through every node tranversed. There 
is also an out-of-band delivery mechanism. However, XTP does not 
offer latency control by itself; it just provides a priority 
mechanism. 


The selective acknowledgement, fast negative acknowledgement, and 
selective retransmission permit an application to choose an 
appropriate level of error control. The combination of the priority 
mechanism and these error-control mechanisms is likely to approach 
the latency and synchronization requirements of remote conferencing. 


Noninteractive audio and video, as well as graphics presentation, can 
be accommodated in many ways by the application. It is important 
that the transport layer provides adequate mechanisms to deliver the 
appropriate data streams in a manner compatible with the 
applications. These applications can probably be accomplished by 
means of extant protocols, as well as XTP. 


The scalability of the solution will be a function of the standards 
used. At the Packet Video Workshop, some of the applications 
sacrificed computer network standards in favor of desired 
performance. This approach usually impedes scalability. From the 
explanation of the applications taking this approach, it appeared 
that using XTP would have provided an adequate transport service for 
the applications. 


XTP was designed to provide mechanisms to accommodate application 
requirements, that is, the ability to respond to QOS requests. For 
example, guaranteed throughput may be accomplished by using XTP’s 
rate and burst control together with flow control or no flow control. 
Tolerable error rate can be accomplished with partially error 
controlled connections (PECC), a service which can be placed in the 
application or just above the transport layer [PECC92]. Motion 
artifacts and varying degrees of compression should be done above the 
transport layer in coordination with the transport layer or possibly 
in a network management function. 


3.1. Synthesize the Hardware Fabrication Process into the Design 


To produce an affordable solution, the hardware fabrication process 
should be a design consideration. Technologies are evolving too 
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rapidly to assume that a generic protocol design will anticipate all 
fabrication advances, but this fact should not impede use of the 
features of advanced hardware fabrication processes. 


System interface problems and VLSI techniques should be considered in 
the specification of the protocol. An examination of the ATM and 
SONET standards appears to support this philosophy. Similarly, 
NETBLT and VMTP design efforts seem to support this approach. XTP 
does use it. 


It is very helpful to break down the protocol into parallel-state 
machines for execution on more inexpensive hardware. This procedure 
reduces the context switching and interrupt handling requirements of 
the hardware, thereby decreasing production costs while producing a 
scalable protocol machine. 


4. Multimedia Applications over XTP 


In parallel with the IETF efforts to enable multimedia applications 
such as remote conferencing, the XTP forum members have been 
experimenting with major elements of these applications. 


(1) At the University of Virginia, more than 100 simulated voice 
channels were run on an FDDI network [UVAVOICE92]. The 
purpose of this experiment was to test the limits of FDDI 
and a software version of XTP in a simulated interactive 
voice environment. Multicasted, noninteractive video has 
been supported there for several years. 


UVa also has a video-mail demo over XTP/FDDI that uses 
Fluent multimedia interface and standard JPEG compression. 
This PC-based demo delivers full frame, full color, 30 
frames/sec video from any network disk to a remote VGA 
screen. It is important that users could not discern any 
difference in playback between a local disk and a remote 
disk. An Xpress File System (XFS) is used on server and 
client systems. 


(2) The Technical University of Berlin, Germany, reports that 
the coordination, implementation, and operation of 
multimedia services (CIO) of the R&D in Advanced 
Communications Technologies in Europe (RACE) is using XTP as 
a starting point for design [XTPRACE]. 


(3) At the Naval Command, Control, and Ocean Surveillance Center 


Research, Development, Test and Evaluation Division NRaD 
(formerly the Naval Ocean Systems Command (NOSC)), voice is 
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multicasted over XTP/FDDI. A simple multicast is 
distributed to a group with a latency of around 25 ms, where 
the latency represents delay from the voice signal from the 
microphone to the audio signal to the speaker. This group 
is currently doing research on an n-party multicast of voice 
(telephone conference-call paradigm [n x n multicast]). 


(4) Commercially, Starlight Networks Inc., migrated a subset of 
XTP into the transport layer of its video application 
server. By using XTP rate control, full-motion, full-screen 
compressed video is delivered at a constant 1.2 Mbps, over 
switched-hub Ethernet to viewstations. This network 
delivers at least 10 simultaneous video streams. 


Therefore, XTP has been used in applications that were previously 
placed over IP or even a data link layer. 


5. Policy versus Mechanism 


Separating protocol policies and mechanisms [XTPbk] permits adoption 
of new policies without altering offered mechanisms. An excellent 
example is UVa’s Partially Error Controlled Connections (PECC). This 
control system maximizes error control in such a way that receiving 
FIFOs are never starved i.e., the application, driver, or operating 
system buffer control, and not the transport layer becomes the 
bottleneck. 


Because XTP is mechanism-rich and policy-tolerant, this very dynamic 
error control policy mechanism is possible. Separating policy and 
mechanism permits an error-control or flow-control policy to adapt to 
the data link layer conditions without shutting down a connection and 
rebuilding (or multiplexing) a new one on a different protocol stack. 
This may also provide an easier way for a network management 
subsystem to maintain a desired QOS. 


6. Summary 


Remote conferencing presents new opportunities for research, 
business, and administration. Although some are proposing that only 
classical circuit-switched mechanisms be used, most network engineers 
are searching for ways to use the new features of FDDI, SMDS, and ATM 
in multimedia applications such as remote conferencing. Some new 
applications have been placed directly on a data link layer. New 
Transport/Network layer combinations have been proposed and are being 
tested. It is believed that consideration should be given to XTP as 
a possible solution because its forum membership includes commercial, 
government, and research institutions, some of which have implemented 
various applications that contribute to an overall remote- 
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conferencing application. 
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Security Considerations 

Security issues are discussed in section 2.1. 
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